Thanks! The reason we haven't done this to date is that since ds-test is used in basically every dapptools project, and dapp currently expects that there is a single globally consistent version of every package in the tree, an update to ds-test has historically been rather painful to orchestrate since it generally requires recursively updating a huge amount of submodules. For this reason we decided to keep the Hevm interface out of ds-test since it let us add new cheatcodes without having to go through the hassle of a ds-test update.

However, once dapphub/dapptools#719 lands, this shouldn't be nearly as much of an issue, and I would be happy to add the interface to ds-test.

I do have a few requests however:

1. Can you please add a storage var hevm to the DSTest contract (e.g. Hevm hevm = Hevm(HEVM_ADDRESS);), this way users of ds-test can just call hevm.<cheat-code> in any contract that inherits from DSTest.
2. Can you please reformat the Hevm interface declaration in hevm.sol so that each method declaration is on one line, and there are no newlines between method declarations (like this).

Awesome will add them soon.

Thanks! The reason we haven't done this to date is that since ds-test is used in basically every dapptools project, and dapp currently expects that there is a single globally consistent version of every package in the tree, an update to ds-test has historically been rather painful to orchestrate since it generally requires recursively updating a huge amount of submodules. For this reason we decided to keep the Hevm interface out of ds-test since it let us add new cheatcodes without having to go through the hassle of a ds-test update.

However, once dapphub/dapptools#719 lands, this shouldn't be nearly as much of an issue, and I would be happy to add the interface to ds-test.

I do have a few requests however:

1. Can you please add a storage var hevm to the DSTest contract (e.g. Hevm hevm = Hevm(HEVM_ADDRESS);), this way users of ds-test can just call hevm.<cheat-code> in any contract that inherits from DSTest.
2. Can you please reformat the Hevm interface declaration in hevm.sol so that each method declaration is on one line, and there are no newlines between method declarations (like this).

Just committed the suggested changes. And tested them in a local repo 😉

@d-xo would having an hevm contract as a public state var for every test mess with the invariant targeting?

Might force everyone to use an targetContracts method

Test contracts are excluded by default from invariant tests so I think we should be fine.

Test contracts are excluded by default from invariant tests so I think we should be fine.

But Hevm isn't a test contract?

I mean its not really even a real contract but just want to make sure it being exported as a state var won't cause it to be picked up by the invariant fuzzer.

Does the calling the hevm address with IS_TEST() return true?

oh hehe, whoops I was sleepy this morning 🤦‍♀️. We also ignore contracts that have no code so hevm is not included in invariant tests by default.